Thanks for the help eskimo and adverse camber.I am Admin in one team. In this team I can see "Additional Entitlements" step if I am creating Mac App Store (in Distribution section) profile (by using "Apple Distribution" certificate), and in the listbox, aside from Default, there is also "System Extension EndpointSecurity for Mac (Dist)" in the listbox. This means that the entitlement has been correctly assigned to the team. However this "Additional Entitlements" step is not available for me when creating either "Developer ID" distribution profile or "macOS App Development" provisioning profile; those are the two I need, as we distribute outside of App Store.Were I not an Admin in the team, I would say that there is some access issue, as a colleague who is App Manager and Developer in another team can, unlike me, see the "Additional Entitlements" step when creating "macOS App Development" provisioning profile (although in that team we do not have the ES entitlement requested). According to https://developer.apple.com/support/roles/ Admin is a superset of App Manager and Developer, so this makes no sense...

Hello, I forgot to create an issue; I have done it now, it is FB7759755

Hello, I simply intercept all connections to specific ports (80, 443 etc.). The issue is not that I get the hostname, that is expected, the problem is that there seems to be no way how to set the actual endpoint afterwards for the flow. How should the flow know where it connects to? AFAIK the only interaction between the internal side of transparent proxy (tcp flow) and my external one (Network.framework based connection; btw sometimes I have multiple such connections at once for single internal endpoint) is the [flow setMetadata: parameters]; which ensures that the external connection is attributed to the originating process. IMO the endpoint should be settable, or the  [flow openWithLocalEndpoint:nullptr completionHandler:] should also accept remoteEndpoint. Kind regards,

And just so you know: Safari used to use some kind of private getsockopt operation to get the remote address; this getsockopt could not be intercepted by a sfltfilter based kext (some kind of hack in kernel code prevented the opt to go to the getsockopt filter function). sfgetpeername callback did not apply either. This is making sflt_filter based transparent proxy not correctly work with Safari. I have even talked about this with some Sext Apple dev in the past. For this case however this information is hopefully not really relevant, as this is not Safari specific issue.

Concerning "If we block one flow, the socket can no longer be used to communicate with the specific remote IP and fails with EPIPE": Socket Proxy generates new NEFilterFlow for every "pseudo connection"; it seems this means that you get one flow for every "local ip:local port: remote ip: remote port" tuple. In other words, every UDP BSD socket generates as many flows as is the number of "remote ip:remote port" targets it actually contacts. Every such flow can be left in undecided state, you can inspect the traffic etc. But the moment we .drop it, communication with the target becomes impossible from that socket from now on (sendmsg() to it fails with error). Please note traffic to other targets is still working fine. This behaviour is sufficiently weird that most of the apps can not cope with this. I am pretty sure this breaks mDNSResponder process also if you do it to it. Rather than recreating the socket on such error, it simply ignores it. This may lead to weird states like half of dns works because one dns server can be contacted from the socket but half not because the other one was rendered unusable. I have not double checked this mDNSResponder behaviour so please note that I may be wrong (I did analyse it quite a long time ago). But for my test app it behaves like this. Even fixing mDNSResponder does not fix the issue as apps can use their own messaging (dig, libresolv, other 3rd parties) and they will not be ready for this. In general people do not really seem to handle weird errors of UDP sendmsg. IMO for selective filtering of UDP, Socket Filter is not a feasible approach.